home *** CD-ROM | disk | FTP | other *** search
/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / umich / telecomm / stadel / stadel2.zoo / document / doors.doc < prev    next >
Encoding:
Text File  |  1989-02-10  |  6.2 KB  |  133 lines
  1.                            Doorways in STadel
  2.  
  3.     Version 3.2a of STadel supports `doors', which are a way for a 
  4.     sysop to allow user access to external programs.  STadel supports
  5.     doorways via the `!' prefix, which (amazingly enough) works like a
  6.     shell escape in many programs found on the Unix(tm) operating
  7.     system.  
  8.  
  9.     The user interface to doors is very simple.  The user merely 
  10.     types a `!' followed by the name of the doorway.  For example, if
  11.     you've got zmodem file transfers enabled under the names `rz' (to
  12.     read a file via zmodem) and `ez' (to enter a file via zmodem), a
  13.     user would type `!rz FOO' to read FOO via Zmodem and `!ez FOO' to
  14.     enter foo via Zmodem.  
  15.  
  16.     The sysop can control access to doorways by the users access 
  17.     level (normal user, aide, or sysop) and by the type of room that
  18.     the user is currently in.  A doorway may allow the user to pass a
  19.     command tail in (in which case the system scans the command tail
  20.     to make sure that there are no `:'s or `\'s in it.) and/or it may
  21.     append the users name to the command line.  The list of valid
  22.     doorways is kept in an ordinary ascii file (CTDLDOOR.SYS) in your
  23.     #sysDir.  CTDLDOOR.SYS is composed of lines of the form 
  24.  
  25.     <doorname> <mode> <program-name> [command tail] [#comment]
  26.  
  27.     <doorname> is the name the BBS uses for this doorway.  
  28.  
  29.     <mode> tells STadel what permissions/restrictions there are on 
  30.     this command.  It is composed of the following characters:  
  31.  
  32.         u    - anyone may use this doorway.
  33.         a   - only aides and sysops may use this doorway.
  34.         s   - only sysops may use this doorway.
  35.         d   - this doorway must be executed from within a
  36.           directory room.
  37.         r   - (for above) the directory must be readable.
  38.         w   - (for above) the directory must be writable.
  39.         t   - the user may provide a command tail for this
  40.           command.
  41.         n   - pass the username to this command as part of
  42.           the command tail.
  43.         l   - the rest of the mode string is the directory
  44.           to link this command to.  If your mode string
  45.           ends with `lc:\bin', stadel will make `c:\bin'
  46.           your current directory when running this
  47.           command.
  48.         @ -   the rest of the mode string is the room that
  49.           this command is valid in.  If you set up a
  50.           room name, this door will _not_ work outside
  51.           of the given room (@Mail means that this
  52.           command will only work in Mail>.)  You may
  53.           not use both this command and the `l' command.
  54.  
  55.     <program-name> is the full pathname -- including extention -- of
  56.     the program associated with this doorway.  
  57.  
  58.     [command tail] is the optional command tail to pass to this 
  59.     doorway upon execution.  If the doorway allows a user-supplied 
  60.     command tail, it will be appended to this command tail.  
  61.     (usernames are appended after everything else) 
  62.  
  63.     [#comment] is a descriptive text to print out whenever a user does
  64.     a !?  to se what the current doors are.  
  65.  
  66.     For example, take the case above.  To implement `!rz' and `!ez',
  67.     the sysop would implement the following doorways in CTDLDOOR.SYS:  
  68.  
  69.     >    rz udrt c:\bin\rzsz.ttp # zmodem download
  70.     >   ez udwt c:\bin\rzsz.ttp -n # zmodem upload
  71.     ^   ^      ^             ^     ^
  72.     |   |      |             |     +----- descriptive comment.
  73.     |   |      |             +----------- command tail (optional.)
  74.     |   |      +------------------------- full program name.
  75.     |   +-------------------------------- permissions.
  76.     +------------------------------------ doorway name.
  77.  
  78.     The mode of rz and ez is:  `u' = everybody can execute this 
  79.     command;  `d' = this command must be executed in a directory 
  80.     room;  `r'/`w' = this command must be executed in a 
  81.     readable/writable directory room;  and `t' allow the user to pass
  82.     in a command tail.  
  83.  
  84.     If you do a shell escape inside of a directory room, the program 
  85.     will have it's working directory set to the directory that's 
  86.     associated with the room.  
  87.  
  88.     There are a few things to be wary of with shell escapes:  
  89.  
  90.     1) if you have a user-accessable command interpreter or a 
  91.     interactive program that will let you screw around with 
  92.     directories, an unscrupulous user could totally subvert your 
  93.     system.  
  94.  
  95.     2) If you have an interactive shell escape and the user drops 
  96.     carrier, the program will likely wait up until the next call 
  97.     comes in -- and the next caller will have possibly illegal access
  98.     to the system.  
  99.  
  100.     3) If your application depends on any data or overlay files, you 
  101.     should be sure to use the 'l' switch in the mode part of that
  102.     door's line in your ctdldoor.sys file so as to ensure that your
  103.     application can find the files it needs to run.  
  104.  
  105.     4) If you have multiple doors with the same name, place the doors
  106.     with the most restricted usage (e.g.  Sysop only doors, Aide only
  107.     doors, doors that are bound to a room...) last in your
  108.     ctdldoor.sys file.  
  109.  
  110.            Door names that have special meaning to the system.
  111.  
  112.     Some door names have special meaning to STadel;  these doors are 
  113.     bound into the system so that you do not have to do !<name> to 
  114.     access them (though you may access them that way if you wish.) 
  115.  
  116.     The first door with special meaning is the `shell' door.  STadel
  117.     will, in the absence of a #shell in your ctdlcnfg.sys, use the
  118.     last `shell' door in your ctdldoor.sys file for the ^Lo command.  
  119.  
  120.     The second door is the `login' door.  When a user logs in, STadel
  121.     will try to run this door.  Normal restrictions apply, so you may
  122.     have different login doors for people on modem, people on the
  123.     console, normal users, and aides.  If this door is run, your
  124.     LOGIN.BLB file, if any, will not be displayed.  
  125.  
  126.     The third door is the `editor' door.  This door is an external
  127.     editor that can be invoked via the [o]utside editor command from
  128.     the message editor.  Citadel invokes this editor as `<editor>
  129.     <message-temp-file-name>', so if the editor you want to use does
  130.     not understand command lines, DON'T USE IT!  Normal restrictions
  131.     apply, so if you want users to have access to external editors,
  132.     you may.  
  133.